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ABSTRACT 



In order to transparently redirect an HTTP connection 
request that is directed to an origin server (107) to a proxy 
cache (110-1), a proxy redirector (104) translates the desti- 
nation address of packets directed to the origin server to the 
address of the proxy. During a handshaking procedure, a 
TCP connection is transparently established between the 
client (110-1) and the proxy cache. When the client transmits 
a GET request to what it thinks is the origin server, which 
request specifies the complete address of an object at that 
origin server that it wants a copy of, the proxy redirector 
modifies the complete address specified in that GET request 
before it is sent to the proxy cache. Specifically, the IP 
address of the origin server found in the destination field in 
the IP header of the one or more packets from the client 
containing the GET request is added by the proxy redirector 
as a prefix to the complete URL in the GET request to form 
an absolute URL. The proxy cache determines from that 
absolute URL whether it has the requested object stored in 
its cache. If it does, it sends the object back to the proxy 
redirector, which masquerades those packets as coming from 
the origin server by translating their destination address to 
the address of the client and their source address to that of 
the origin server. If the proxy does not have the requested 
object, a separate TCP connection is established between the 
proxy and the origin server from where the object is 
retrieved and then forwarded over the TCP connection 
between the client and the proxy. In order to account for the 
additional number of bytes in the GET request, an acknowl- 
edgement sequence number in packets returned from the 
proxy that logically follow receipt of the GET request are 
decremented by that number by the proxy redirector before 
being forwarded to the client. Similarly, a sequence number 
in packets transmitted by the client subsequent to the GET 
request are incremented by that number before being for- 
warded by the proxy redirector to the proxy cache. 

55 Claims, 4 Drawing Sheets 
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METHOD AND APPARATUS FOR an IP address. First, a SYN packet is sent from the client to 

TRANSPARENTLY DIRECTING REQUESTS *h at origin server, wherein the destination IP address sped- 

FOR WEB OBJECTS TO PROXY CACHES fied } n toe packet is the DNS-determined IP address of the 

origin server and the destination port number for an HTTP 

FIELD OF THE INVENTION 5 request is conventionally port 80. The source IP address and 

m . . , , . . , port number of the packet are the IP address and port number 

This invention relates to packet-switched computer ^ the cIient ^ client IP address ^ generaUy 

networks, and more particularly, to a method and apparatus assigned to the client by an ISP and the client port number 

in such a network for transparently intercepting client web ^ dynamically assigned by the protocol stack in the client, 

requests and redirecting them to proxy caches. ^ The origin server then responds back to the client with an 

KA ^ rDni IMPk ™ ™ c Txn/cAmow ACK SYN P acket ™ which me destination IP address and 

BACKGROUND OF THE INVENTION destination port are the client's IP address and port number 

Proxy caching is currently used to decrease both the and the packet's source IP address and port number are the 

latency of object retrieval and traffic on the Internet back- server's IP address and the server's port number, the latter 

bone. As is well known, if a proxy cache has stored a copy generaUy being port 80. After receipt of the ACK SYN 

of an object from an origin server that has been requested by P acket > me client scad& one or more P ackets to me ori S ul 

a client, the requested object is supplied to the client from *™*> wm ^ P ackets T 1 ^* GE J J° e °F 

the proxy cache rather than from the origin server. This, ^quest includes a complete VKL, which identifies to that 

therefore, obviates the need to send the request over a wide ™ the ob J e * lhe on &? ™5? tha f^ 

' , # x<_ ■» i a. chent wants a copy of. Unlike an absolute URL which 

area network, such as the Internet, to the origin server where „„ . , , . - 4 K J c , , \ * 

4 . . . , . . , . , , , 7 r A . . 20 includes both site information (e.g., www.yahoo.com), and 

the original object is stored and the responsive transmission object information ( in dex.html), a complete URL only 

of a copy of the requested object back over the network to identifies ^ particular (c g y index.html) that is 

the requesting client. requested since the packers) containing the GET request is 

Direction of a request from a client to a proxy cache to sent to the proper origin server site by means of the 

determine whether a requested copy of an object is stored in ^ destination address of the packet(s). 

the cache can be accomplished either transparently or non- When a browser is configured to non-transparently send 

transparently to the client. Non-transparent redirection is all requests to a proxy, a GET request is formulated by the 

accomplished through the client's browser program which is browser that includes the absolute URL of the requested 

configured to send all object requests to a designated proxy object. That absolute URL is then used by the proxy to 

cache at a specified address. Generally, a browser can be 33 establish a separate TCP connection to the origin server if 

configured to send all of its client requests to a designated the proxy does not have a copy of the requested object in its 

proxy cache if the client is connected on a Local Area cache. The proxy requires the absolute URL since the 

Network (LAN), or on an Intranet behind a firewall, where destination address of the packets to the proxy is set by the 

a proxy cache associated with that LAN or Intranet is browser to the IP address of the proxy rather than the IP 

located. When clients are served by a large Internet Service 35 address of the origin server. Thus, in order to determine 

Provider (ISP), however, it is not advantageous from the whether it has the object in its cache and if not establish a 

ISP's standpoint to allow its subscribers to set their browsers connection to the origin server, the proxy requires the 

to a specific proxy cache associated with the ISP. A large ISP absolute URL of the origin server in the GET request, 

likely will have many proxy caches in several locations and when requests are transparently directed to a proxy cache, 

will thus want to maintain control over which of its several ^ however, the client browser is unaware that the request is 

particular proxy caches a client request is directed. Further, being directed to the proxy and is possibly being fulfilled 

if a proxy cache whose address is statically set in a client's fr om t he cache. Rather, the client's browser needs to "think" 

browser becomes inoperative, all client requests will fail. that it is connected to the origin server to which its SYN and 

It is therefore more desirable from an ISP's standpoint the packet(s) containing the GET request are addressed, 

with respect to latency and minimizing traffic onto and off of 45 Such origin server IP address is determined by the browser 

the network to transparently intercept a client's web request through a. DNS look-up. Further, the source address of the 

and send it to one of its operative proxy caches to determine ACK SYN packet and the packets containing the requested 

whether a copy of the requested object is stored there. If a object must be that same origin server IP address or they will 

copy of the requested object is then found to be stored in that not be recognized by the browser as being the responsive 

proxy cache, a copy of the object is sent to the client, which so packets to the SYN packet and the request for the object, 

is unaware that it has been served an object from the proxy Thus, in order to transparently send object requests to a 

cache rather than from the origin server to which it made the proxy cache, a mechanism must be in place along the packet 

request. If the proxy cache does not hold a copy of the transmission path to intercept an initial SYN packet sent by 

requested object, then a separate connection is established a browser and to redirect it to the proxy cache to establish 

between the proxy cache and the origin server to obtain a 55 a TCP connection. The proxy cache must then masquerade 

copy of the object, which when returned to the proxy is sent as the origin server when sending the ACK SYN packet back 

to the client over the connection established between the to the client by using the origin server's IP address and port 

client and the proxy. number as the source address of that packet. Further, the 

When a client specifies a URL of the object it is requesting subsequent packet(s) containing a GET request must be 

a copy of, a Domain Name Server (DNS) look-up is per- 60 redirected to the proxy cache and the request fulfilled either 

formed to determine from the URL an IP address of an origin from the cache or via a separate TCP connection from the 

server which has that requested object. As a result of that proxy to the origin server. In either case, the source address 

look-up, an IP address is returned to the client of one of what of packets sent back to the client must be the origin server's 

may be several substantially equivalent servers that contain IP address and port number to which the packets sent by the 

that object. The client then establishes a TCP connection to 65 client are addressed. 

that server using a three-way handshake mechanism. Such a In order for packets associated with a request for an object 

connection is determined at each end by a port number and to be redirected to a proxy cache connected somewhere in 
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the network, a Layer 4 (L4) switch on the packet path and then the packet(s) containing the GET request to the 
"looks" at the port number of a destination address of a SYN origin server, the L4 switch again performs a NAT, trans- 
request packet. Since HTTP connection requests are gener- lating the destination IP address to the IP address of the 
ally directed to port 80 of an origin server, the L4 switch proxy. Thus, when the packers) containing the GET request 
transparently redirects all packets having a port number of 5 is received by the proxy, it does not know the IP address of 
80 in the destination address. The SYN packet is thus sent the origin server as in the directly connected proxy arrange- 
to a selected proxy cache. In order for the proxy cache to ment described above. The proxy must therefore look at the 
properly respond to the client, as noted, it must know the logical name in the HOST field and perform a DNS look-up 
absolute URL of the requested object and packets returned to determine that site's IP address. The proxy then uses that 
to the client must masquerade as coming from the origin 10 IP address in combination with the complete URL in the 
server. Unlike the non-transparent caching method previ- GET request to form an absolute URL from which it 
ously described in which the browser formulates a GET determines whether it has the requested object in its cache, 
request with the absolute URL, for transparent caching the If it doesn't, a separate TCP connection is established from 
absolute URL must be provided in some manner to the proxy the proxy to that absolute URL to retrieve that object, which 
cache in order for the proxy to determine whether it in fact 15 is returned to the proxy. Whether the object is found in the 
has the requested object in its cache, or whether it must proxy cache or is retrieved over the separate connection 
establish a separate TCP connection to the origin server to from the origin server, it is forwarded back to the L4 switch 
request the object. In the prior art, when one or more caches where a NAT and PAT are performed to translate the 
are directly connected to the L4 switch, the switch chooses destination address to that of the client and to translate the 
one of the caches and transparently forwards the packets to 20 source address to the particular origin server to which the 
that proxy without modifying the source or destination client's request was directed. It should be noted that the 
address of the packets. The proxy, working in a promiscuous source address of the origin server obtained when the 
TCP mode accepts all incoming packets regardless of their client's browser initiates a DNS look-up using the origin 
destination address. The proxy, then receiving the SYN server's absolute URL may not be the same IP address 
packet with the origin server's destination address and the 25 obtained when the proxy performs a DNS look-up using the 
client's source address, can respond to SYN packet with an combination of the site URL in the HOST field and the 
ACK SYN packet. This ACK SYN packet has the client's complete URL in the GET request, 
address as a destination address and a source address mas- The above described techniques for performing transpar- 
querading as the origin server address. This packet is trans- ent proxy caching have several disadvantages. Firstly, use of 
ported through the L4 switch onto the network over the TCP 30 a HOST field to specify a logical name of an origin server 
connection back to the client. The subsequent packers) with is not currently incorporated within the presently employed 
the GET request from the client is redirected by the L4 HTTP1.0 standards. Thus, a HOST field may not be present 
switch to the directly connected proxy. Since the GET in the packers) containing a GET request. Where, as 
packet(s) only contains the complete URL, the proxy must described above, the information in the HOST field is 
formulate the absolute URL to determine whether its has the 35 necessary to form an absolute URL to determine whether the 
requested object in its cache or whether is must establish a proxy cache has the requested object and, if not, to establish 
separate TCP connection to the origin server. The proxy a connection to an origin server from the proxy, the absence 
forms the absolute URL by prefixing the complete URL in of the HOST field results in an unfilled request. Secondly, 
the GET request with the IP address of the origin server in the prior art techniques require the proxy cache to perform 
the destination address of the packet. The proxy can then 40 the function of forming an absolute URL from the informa- 
determine whether it has the object and, if not, establish a tion in the HOST field and in the packet(s) containing the 
TCP connection to that absolute address. If that particular GET request. Thus, standard proxy caches which expect the 
origin server at that IP address should be inoperative, the client's browser to produce the absolute URL cannot be 
proxy can alternatively prefix the complete URL in the GET used. A methodology for transparent proxy caching that is 
request with the logical name of the site indicated in the 45 transparent to both the client and the proxy is desirable to 
HOST field in the packet(s) containing the GET request. avoid modification to the program that controls proxy cache 
In the prior art, if the proxy cache is not directly connected operations. Standard proxy caches could thus be employed 
to the IA switch, then the L4 switch must perform a network anywhere in the network without the need for a special 
address translation (NAT) and port address translation (PAT) implementation. 

on those packets directed to port 80 of an origin server. 50 The above described prior art techniques have even 

Specifically, when the L4 switch receives a SYN packet to further disadvantages with respect to persistent connections 

initiate a TCP connection from a client to an origin server, defined by the HTTP1.1 standards. As defined by these 

it translates the destination address of the packet from the IP standards, a persistent connection enables a client to send 

address and port number of the origin server to the IP plural GET requests over the same TCP connection once that 

address and port number of a selected proxy cache. Further, 55 connection has been established between two endpoints. 

the switch translates the source address of the packet from When a prior art transparent proxy cache is interposed on the 

the clients IP address and port number to its own IP address connection, a client may "think" it has established a persis- 

and a port number. When the proxy responds with an ACK tent connection to the specific origin server determined 

SYN packet, it therefore responds to the L4 switch where a through the DNS look-up. The connection in reality, 

NAT translates the destination IP address from the IP address 60 however, is transparently diverted by the L4 switch to a 

of the LA switch to the IP address of the client, and translates proxy cache. The proxy cache, in response to a DNS look-up 

the source IP address from the IP address of the proxy to IP using the logical name in the HOST field, may be directed 

address of the origin server. A PAT also translates the port to an equivalent origin server at a different IP address, 

number in the destination address from that of the L4 switch Further, as each subsequent GET request is received by the 

to that of the client, and translates the port number in the 65 proxy from the client within the client's perceived persistent 

source address from that of the proxy to that of the origin connection, each responsive DNS look-up to the logical 

server (usually 80). When the client sends an ACK packet name may direct a connection to an even different IP address 
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of an equivalent origin server. As a result, the advantages of prefixed by the proxy redirector to form the absolute URL 

a transaction-oriented persistent connection in which a (whether the GET request is one or more segments long) is 

server is capable of maintaining state information through- less than or equal to the actual MSS that the proxy can 

out the connection, are lost. A methodology is desirable that receive. 

maintains penastence to the same origin setver to which the 5 DESCRIPTION OF THE DRAWING 

clients browser is directed, or to a same equivalent origin 

server throughout the duration of the persistent connection. FIG. 1 is a block diagram of a network that includes a 

proxy redirector that transparently sends requests from a 

SUMMARY OF THE INVENTION clieQl tQ a proxy cache by changing the destination address 

The problems associated with the prior art techniques for 10 of packets in a client request from that of the origin server 

transparent proxy caching are eliminated by the present to that of a proxy and the source address from that of the 

invention. In accordance with the present invention, a client to that of the switching entity and, in accordance with 

switching entity, such as the L4 switch (referred to herein- the present invention, modifies a GET request to include the 

after as a proxy redirector), through which the packets flow, destination address of the origin server, 

is provided with the functionalities at the IP level necessary 15 FIG. 2 is a block diagram showing the proxy redirector 

to transform the complete URL in each GET request trans- implemented on a programmable network element that 

mitted by a client to an appropriate absolute URL. manipulates packets in accordance with instructions pro- 

Specifically, the IP address found in the destination field in vided by a loaded program; and 

the IP header of the packeus) from the client containing the mGS 3 4, 5 and 6 are flow charts detailing the operation 

GET request are added as a prefix by the proxy redirector to 20 0 f the proxy redirector. 
the complete URL in the GET request. As a result, the 

complete URL in the GET request is modified to form an DETAILED DESCRIPTION 
absolute URL which, when received by the proxy cache, is With reference to FIG. 1, a plurality of clients 101- 
directly used to determine if the requested object is stored in 1-101-N are connected to a local area network (LAN) 102, 
the cache and, if not, to establish a separate TCP connection 25 such as an Ethernet. LAN 102, which, in turn, is connected 
to the origin server. The GET request received by the proxy through a router 103 to a Level 4 (L4) switch 104 (proxy 
is thus equivalent to what it would expect to receive if it redirector) which interfaces the LAN with a wide area 
were operating in the non-transparent mode. network (WAN) 105, such as the Internet. Although shown 
Advantageously, if a persistent connection is established, as two separate elements, the functionalities of router 103 
each subsequent GET request has the same IP address prefix 30 and proxy redirector 104 can in actual practice be combined 
determined by the initial DNS look-up by the client. in a single unit. All requests from any of the clients con- 
By modifying the GET request at the proxy redirector to nected to LAN 102 for objects stored in servers connected 
include the destination address of the origin server, the to the Internet 105 traverse proxy redirector 104 onto the 
number of bytes at the IP level in the packet containing the Internet. The packets comprising such requests, which 
resultant absolute address are increased by the number of 35 include the standardized packets that establish a TCP 
bytes in the prefix. Included in the header within each packet connection, are directed to an IP destination address and port 
is a sequence number (seq) that provides an indication of the number indicated in the IP header of each packet originating 
position of the first byte number in the payload. Thus, when from a client source address that includes a client IP address 
the IP address is added to a packet, the sequence number of and port number. Similarly, responses to such requests from 
each of the subsequent packets needs to be incremented by 40 an origin server connected to Internet 105 are directed via an 
the count of the added bytes. Further, an acknowledgement IP destination address that is equal to the client's IP address 
sequence number (ack_seq) in the header on the packets and port number from which the request originated, and 
returned from the proxy or the origin server that logically have as a source address the server's IP address and port 
follow receipt of the GET packet(s) at the origin server number. All such packets directed to any of the clients 
needs to be decremented by the proxy redirector before 45 101-1-101-N from any server connected to Internet 105 pass 
being forwarded to the client to avoid confusing the client through proxy redirector 104. 

with respect to what the sequence number of the next byte When any of the clients connected to LAN 102, such as 

it sends should be. Further, if the GET request sent by the client 101-1, makes a request through a browser for an 

client encompasses more than one TCP segment, then the object by specifying a logical URL, a domain name server 

extra bytes in the first of the segments caused by the 50 (DNS) 105 connected locally or on Internet 105, as shown, 

additional bytes added to the URL are shifted into the second is accessed to perform a database look-up based on that 

segment, and the resultant now extra bytes in the second logical name. An associated IP address is men returned to the 

segment are shifted into the third segment, etc., until the last browser. The IP address returned to the browser is the IP 

of the segments. In order to preclude the necessity of address of a particular origin server which contains the 5 

requiring an extra segment to be added to the GET request 55 object requested through the logical URL. Since a logical 

to accommodate the extra bytes, the client sending the GET name may in fact be associated with a plurality of essentially 

request, is deceived into sending segments whose maximum equivalent origin servers, such as servers 107 and 109, the 

size is less than what can actually be received by the proxy particular IP address returned to the client browser chosen 

as indicated by a maximum segment size (MSS) field in by DNS 106 may be determined in a round-robin manner, 

packets from the proxy. The proxy redirector, upon receipt 60 When DNS 106 selects an origin server corresponding to the 

of the On, ACK SYN packet from the proxy, reduces the logical URL, the IP address of the selected origin server, 

MSS parameter received from the proxy by the amount of such as, for example, the IP address of origin server 107, is 

the number of bytes that will be added to the GET request returned to the browser in the requesting client 101-1. That 

before that parameter is forwarded to the client. Thus, when IP address then serves as the IP address to which packets 

the client next sends a GET request, each segment is limited 65 directed to the origin server from the client are directed, 

to the reduced MSS, thereby insuring that the segment size Conventionally, http requests are usually directed to port 80 

of a last segment in a GET request after the IP address is of an origin server. 
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With the IP address of the origin server determined and 
returned to the client, the browser establishes a TCP con- 
nection between the client and the origin server through a 
three-way handshaking process. Specifically, a SYN packet, 
addressed to the IP address of the selected origin server, is 
sent by the client. Handshaking is completed when the client 
receives an acknowledgement of receipt of that SYN packet 
through an ACK SYN packet sent by that origin server, and 
responds with a ACK packet to the origin server. The 
browser then sends a GET request that specifies the particu- 
lar requested object. 

In accordance with the present invention, once the IP 
address of the origin server corresponding to the logical 
URL name is determined through the DNS look-up, proxy 
redirector 104, rather than establishing a TCP connection to 
the origin server at the determined IP address, transparently 
establishes a TCP connection between the client and a proxy. 
If the requested object is stored in the cache, a copy of that 
object is transparently returned to the requesting client. A 
TCP connection, therefore, is not established over the Inter- 
net 105, to the actual origin server 107 to provide the 
requested object to the requesting client. The coss of trans- 
mitting the request to the origin server over the Internet and 
transmitting the copy of the requested object back over the 
Internet are thereby saved in addition to the time required for 
transmitting such a request over the Internet and waiting for 
a response from the origin server. If the proxy cache to 
which the request is directed does not contain the requested 
object, a separate TCP connection is established between the 
proxy cache and the origin server to obtain a copy of the 
requested object. When the proxy cache then receives the 
copy of the requested object from an origin server over that 
separate TCP connection, the copy is forwarded to the client 
over the original TCP connection that was established 
between the client and the proxy cache. 

In the embodiment shown in FIG. 1, a proxy cache 110-1 
is illustratively shown connected to a LAN 111, which is 
connected to LAN 102 through a router 112. Another proxy 
cache 115 is shown connected on a different LAN 116 
through router 103. Other proxy caches can be located 
anywhere on LANs 102, 111, or 116, on another LAN 
connected to the Internet 105 such as proxy cache 117. 
Proxy redirector 104 selects one of the available proxy 
caches to which to forward client requests based on a metric 
such as least-loaded or round-robin, based on IP header 
information such as the origin server IP address. With 
respect to the latter, all objects from a specific origin server 
will be served by a specific proxy. 

In the preferred embodiment described herein, proxy 
redirector 104 includes a programmable network element of 
the type described in co-pending U.S. patent application Sen 
No. 09/190,355, filed Nov. 12, 1998, which application is 
incorporated herein by reference. As described in that 
application, that programmable network element in the 
preferred embodiment runs on a Linux machine. As shown 
in FIG. 2, the programmable network element 200 includes 
a dispatcher process 202 with which plural different gateway 
programs (204, 205 and 206) register and request access to 
IP packets that fit specific descriptions. Such programs are 
loaded through an admission daemon 210 via a local pro- 
gram injector 211 or a remote program injector 212. A 
gateway program, for example, can request access to incom- 
ing packets to network interface 208 that match certain 
source and destination IP address ranges and port numbers. 
The dispatcher process 202 uses a packet filter 203 in the 
Linux kernel 201 to obtain packets requested by the gateway 
programs and uses a raw IP socket 215 to send packets that 
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have been manipulated in accordance with the gateway 
program back to the kernel for output back to the network 
through filter 203 through network interfaces 208. Library 
functions are provided in the programmable network ele- 
5 ment that enable a gateway program to communicate with 
the dispatcher process 202 to register rules that specify the 
type of IP packets that a gateway program wants diverted to 
it. A gateway program can request either a complete IP 
packet or only the IP and TCP header of a packet and can 
10 change both the header and payload of a packet 

In the present invention, that programmable network 
element is operative in combination with a gateway program 
that manipulates the destination and source addresses of 
packets flowing there through in a manner to be described, 
25 as well as modifying, as will be described, information in the 
packet(s) containing the GET request that specifies the URL 
of the requested object. Specifically, the programmable 
network element in combination with the gateway program 
operates on packets associated with HTTP requests, which 
20 are determined from the destination port number. As previ- 
ously noted, HTTP requests are conventionally addressed to 
port 80 of an origin server. Thus, the programmable network 
element/gateway program which together comprise proxy 
redirector 104 in this embodiment, captures through the 
25 dispatcher process of the programmable network element, 
packets directed to port 80 and then performs address 
translations on those captured packets to re address these 
packets to a selected proxy. With respect to address 
translations, the gateway program translates the destination 
30 IP address of packets addressed to the origin server to the IP 
address of a selected proxy cache and translates the source 
IP address of such packets from that of the client to the IP 
address of proxy redirector 104. Further, in order for proxy 
redirector 104 to identify requests from plural client termi- 
35 nals that are directed to the same proxy, the source port 
number is translated to a bogus ghost port number at the 
proxy redirector. Thus, when proxy cache responds, the 
packets transmitted by the cache have a destination IP 
address of proxy redirector 104 at that bogus port number, 
40 which is distinctly associated with the client. The gateway 
program within proxy redirector 104 then translates the IP 
destination address of these responsive packets from the 
proxy to the IP address of the client and translates the bogus 
destination port number to the port number from which the 
45 client originated its request. Further, the gateway program 
translates the source IP address of such responsive packets 
from that of the proxy to the IP address of the origin server 
and the port number to the port (80) to which the client's 
requests were originally directed. Thus, the packets which 
50 are returned to the client from the proxy masquerade as if 
they had originated from the origin server to which the client 
"believed" its request had been sent. 

By performing the above-described network address 
translations (NATs) and port address translations (PATs), 
55 packets from a client 101-1 are transparently directed by 
proxy redirector 104 to a proxy cache. Responsive packets 
from the proxy cache are sent to proxy redirector 104 where 
they are redirected to client 101-1. 

In establishing a TCP connection that is directed to an 
60 origin server, client 101-1 first transmits a SYN packet, 
which is intercepted by proxy redirector 104. Proxy redi- 
rector 104 selects a proxy cache, such as proxy 110-1, to 
redirect this request and creates a connection control block 
(CCB) to maintain information about the connection. Selec- 
65 tion of the particular proxy is determined, as described 
above, by one of several possible algorithms. The CCB is 
used to store the client IP address and TCP port number and 
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the origin server IP address and TCP port number, both of fixing it with the IP address of the origin server obtained 

which are contained in the IP header of the S YN packet, and from the destination IP address of the packers) containing 

the chosen proxy's IP address. The destination address is the GET request. Thus, Level 7 (application) information is 

then changed to that of the chosen proxy and the packet is modified to assist in level 4 routing, 

sent back to the network for redirection to its new destina- 5 In order to make the URL transformation transparent to 

tion address of the proxy 110-1. All subsequent packets that both the client and proxy cache endpoints, changes in IP and 

originate from the same client with the same TCP port TCP headers are also required. Since the GET request 

number are then forwarded to the same proxy. Proxy 110-1 modification increases the length of the IP packet that carries 

responds with an ACK SYN packet which is directed via its th e GET request, the total length field on the IP header of this 

destination address to proxy redirector 110-1. Proxy redi- 10 packet is increased by an offset. The offset amount is 

rector 104 then translates the source IP address and port recorded in the CCB. In addition, the TCP header contains 

number to those of the origin server and the destination IP sequence numbers (seq) and acknowledgement sequence 

address and port number to those of the client. When the numbers (ack__seq) that need to be translated. The seq in the 

packet arrives at the client the client believes that it is TCP header indicates the byte number of the first byte on this 

connected to the origin server. The client then responds with 15 packet going from the sender to the receiver over the TCP 

an ACK packet to the origin server, which is redirected by session and the ack_seq indicates the byte number of the 

proxy redirector 104 to proxy cache 110-1, to complete the ne xt byte that the sender expects to receive from the 

handshaking process. receiver. For all packets after the GET packet(s) that go from 

After the TCP connection is established between client the client to the proxy cache, the seq is increased by an offset 

101-1 and proxy cache 110-1, client 101-1 sends one or 20 equal to the lengthof(absolute URL)-lengthof(complete 

more packets containing a GET request addressed to the URL) so that the seq matches the byte number of the byte 

origin server. Such packets are thus "captured" by proxy that the proxy cache expects to receive from the client, 

redirector 104 and redirected to proxy cache 110-1. As Similarly, on all packets starting with the acknowledgement 

previously discussed, the GET request sent by the client to the GET packet that go from the proxy cache to the client 

contains only the complete URL sent by the client browser 25 through the proxy redirector, the ack_seq is decreased by 

which in itself provides insufficient information for the the same offset so that the ack_seq matches the byte number 

proxy cache to determine whether it has the requested object of the byte that the proxy cache would expect the client to 

and, if not, to forward it to the origin server which does. In send in the next packet following the GET packet. By 

accordance with the present invention, the gateway program performing these changes in the header, the client and proxy 

that is operative with the programmable network element of 30 cache endpoints remain unaware of the modification in the 

the proxy redirector 104, captures this packet or packets and, GET packets from the complete URL to the absolute URL. 

in addition to previously described address translations, Table 1 illustrates the URL and other header transforma- 

transforms the complete URL to an absolute URL by pre- tions performed 



TABLE 1 



Arriving packet: 

— > beginning of packet header dump < — 

— > IP header: vcrsion=4 hdr_Jcn-5 TOS-0 pkt_Jen=346 id -6027 6 

frag_off-4000H TTL=64 protocol-6 cksum-1792H 

saddr~135. 104.25 .243 daddr=204.71 .200.244 
— > TCP header sports 1273 dport=80 seq=2189084427 ack_seq-32664495l7 

tcp_hdr_len-5 9ags=ACK PSH 

resl«4)H res2-0H window-31856 cksum=162H urgenL-0 
— > beginning of packet data dump < — 
GET /a/ya/yahoo mail/pro mo l.gif HTTP/1.0 
Referer: httpVAvww.yahoo.com/ 
Connection: Keep-Alive 

User-Agent: MoziIla/4.05 [en] (Xll; U; Linux 2.1.103 1686) 
Host: us.yimg.com 

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg image/png 
Accept- Language: en 
Accept-Charset: iso-8859-1, *,utf 8 
Modified to: 



— > beginning of packet header dump < — 

— > IP header: version=4 hdr_Jen-5 TOS-0 pkt_Jen=367 id-60276 

frag_off-4000H TTL-64 protocol-6 cksum-1792H 

saddr-135.104.25.245 daddr-135.1 04.25.31 
— > TCP header sport-5000 dport-7000 seq-2189084427 ack_seq-326 64495 17 

tcp_hdr_len=>5 flags-ACK PSH 

res 1 -OH res2^)H window-31856 cksum-162H urgent-0 
— > beginning of packet data dump < — 
GET http://204.71 .200.244/a/ya/y^^ HTTP/1.0 
Referer: http://www.yahoo.corn/ 
Connection: Keep-Alive 

User-Agent: MozMa/4.05 [en] (Xll; U; Linux 21.103 i686) 
Host: us.yimg.com 
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TABLE 1 -continued 

Accept: image/gif, image/x-xbitmap, imagc/Jpeg, image/pjpeg image/png 
Acccpt-Language: en 
Accept-Charset: iso-8859-1, *,utf 8 



on a GET packet that arrives at proxy redirector 104 from a 
client 101-1. The packet is destined to an origin server at a 
destination IP address (daddr) 204.71.200.244 
(www.yahoo.com) at a destination port (dport) 80, request- 
ing object /a/ya/yahoomail/promol.gif. As can be noted in 
the modified packet, the packet is redirected to a proxy cache 
110-1 at IP address 135.104.25.31 port 7000 by changing the 
daddr and dport header information. Also, the complete URL 
of the object in the GET request is modified in the translated 
packet by prefixing it with http://204.71.200.244 to form the 
absolute URL, where that prefix is obtained from the daddr 
header in the arriving packet. This transformation increases 
the length of the packet by 21 bytes so that the pkt_Jen field 
in the header is modified from 346 to 367 bytes. Further, the 
source port is modified to a bogus port number by changing 
sport to 5000. 

Table 2 shows the translations performed by the proxy 
redirector 104 to an acknowledgment from proxy cache 
110-1 to the GET request. The arriving 



length of the GET packet by 21 bytes, proxy redirector 104 
decreases the ack_seq field by the number of bytes added, 
21. Further, proxy redirector 104 translates the destination IP 
address and port number to those of the client 101-1, and the 
source IP address and port number to that of the origin 
server. The modified packet, when received by the client, 
thus appears to the client to have originated from the origin 
server and the ack_seq field indicates a byte number that the 
client would next expect to send having previously sent a 
packet of length 367 bytes. All packets that are subsequently 
sent through the proxy redirector 104 to client 101-1 from 
proxy cache 110-1 are similarly modified to decrement the 
ack^jseq field by the number of bytes, 21, added to the GET 
packet. 

Table 3 illustrates a next packet sent by client 101-1 to the 
origin server after the GET packet. In this packet the 
sequence number (seq) is equal to the modified ack__seq 
sent to the client, as per Table 2. The destination IP address 
and port number are those of the origin server and the source 



TABLE 2 



Arriving packet: 

— > beginning of packet header dump < — 

— > IP header version=4 hdr_len-5 TOS-0 pkLJen-40 id-14559 

frag_off=40O0H TTLf=255 protocol-6 cksum=10eH 

saddr-l 35.104.25.31 daddr-135. 104.25. 245 
— > TCP header: sport-7000 dporfe-5000 scq-3266449517 ack_seo-2189084754 

tcp_hdr_Jen=5 flags=*ACK 

real^)H res2-0H window*-8433 cksum-32H urgent-0 
Modified to: 

— > beginning of packet header dump < — 

— > IP header version-4 hdr_len-5 TOS-0 pkt_len-40 id-14559 

frag_off-4000H TTL-255 protocol-6 cksum-lOeH 

saddr-204.71.200.244 daddr*-135.104.25.243 
— > TCP header: sport=80 dport-1273 seq-32 6644951 7 ack_seq=2189084733 

tcp_hdr _Jen=5 flags-ACK 

resl=0H res2=0H window=8433 cksum-32H urgent-0 



packet is addressed (daddr) to the IP address of the proxy 
redirector at the bogus port (dport) 5000 used by the proxy 
redirector for this TCP connection. The source IP address 
(saddr) and the source port (sport) are those of the proxy 
cache to where the GET request was directed. The ack_seq 
field indicates the byte number of the first byte that is 
expected to be sent in the packet following the GET packet. 
In this example, ack_seq is equal to the sequence number 
(seq) 218908427 of the GET packet plus the length of the 
GET packet, which in this case per Table 1 is 367. Thus 
ack_seq of the arriving packet is 218908754. Since client 
101-1 is unaware that a proxy redirector has increased the 



IP address and port number are those of the client. When 
received by proxy redirector 104, the packet is modified to 
change the source IP address and port number to the IP 
address and bogus port number of the proxy redirector. The 
destination address IP and port number are translated to that 
of proxy cache 110-1. The sequence number (seq) is 
increased by that same value of 21 to match the byte number 
that the proxy cache expects to receive based on the 
sequence number previously received in the GET packet and 
the length, 367, of the GET packet 



50 



55 



TABLE 3 



Arriving packet: 

— > beginning of packet header dump < — 

— > ff header: vcrsion-4 hdr_lcn-5 TOS-0 pkt_lcn-40 id-60281 
frag_off-4000H TTL-64 protocol-6 cksum-18bfH 
saddr-135.104.25.243 daddr-204.71 .200.244 
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TABLE 3 -continued 



— > TCP header: sport-1273 dport-80 seq-21 89084733 aci_scq-3 26 6450977 
tcp_hdrjen«5 flags-ACK 

resl-OH res2-0H wiodow=31856 cksum=d3f7H urgent-0 
Modified to: 

— > beginning of packet header dump < — 

— > IP header: version=4 hdr_len=5 TOS=0 pkt_len=40 id=60281 

frag_off=4000H TTL=64 protocols cksum=18bfH 

saddr=135.104.25.245 daddr=l 35.1 04.2531 
— > TCP header: sport-5000 dport-7000 seq=21 89084754 act_seo=3266450977 

tcp_hdi_Jen=5 flags=ACK 

real "OH rcs2=0H window=.31856 cksum=d3f7H urgcnt=0 



received. All subsequent packets directed to the origin server 
from client 101-1 are similarly modified before being 
directed to proxy cache 110-1. 

In the above-description, it has been assumed that the 
length of the GET request both before modification, and 
after the URL extension is less than the maximum TCP 20 
segment size. In fact, the length of the GET request may be 
longer than one TCP segment. If the length of the GET 
request carrying the complete URL occupies x number of 
TCP segment and, after it is modified to carry the absolute 
URL, it still also fits into that same x number of TCP 25 
segments, then the segment carrying the URL is modified 
and overflowing characters are pipelined from one segment 
to the next. Thus, the overflowing characters from a previous 
packet are prefixed to the start of the next packet, etc., until 
the last packet, which length is increased by the increased 30 
number of bytes due to the URL modification. Therefore, the 
packet length of only the last segment is modified to include 
the characters that have been shifted into that segment. The 
ack_seq parameter in packets from the proxy cache to the 
client is modified starting from the acknowledgment to the 35 
last GET packet. 

If the modification of the URL to the absolute URL could 
cause the last TCP segment of the GET request to overflow 
to another segment, a new TCP segment would need to be 
constructed and injected by the proxy redirector. The proxy 40 
redirector would then need to have the capability to retrans- 
mit this segment if it was lost. Thus, the proxy redirector 
would need to have some TCP layer functionalities. In order 
to avoid adding higher level functionality to the proxy 
redirector, segment sizes are limited to less than what the 45 
proxy cache is actually capable of receiving. When the 
complete URL is transformed to an extended URL, the 
maximum increase in size is 22 bytes, equal to the maximum 
length of an IP address of 15 bytes plus 7 bytes from the 
prefix: http://. The client is deceived to send segments whose 50 
maximum size is 22 bytes less than what the protocol allows 
it to send. The TCP segment size sent by the client is 
determined by what the proxy cache, in its handshake with 
the client, indicates as the maximum segment size it can 
receive. This is indicates by the proxy cache through the 55 
maximum segment size (MSS) field in the ACK SYN 
packet. Accordingly, the proxy redirector 104 intercepts the 
ACK SYN packets and decreases the specified MSS amount 
by 22, For example, if the MSS specified by the proxy cache 
is 1460, it is modified to 1438 by the proxy redirector before 60 
being sent to the client. When the client next sends a GET 
request, the TCP segments are limited to 1438 bytes. In the 
worst case, when the client sends a GET request, 22 bytes 
will be added to the xth TCP segment that carries this 
request. The length of this xth TCP segment will still then be 65 
within the maximum length specified by the proxy cache. If 
the event that the proxy cache does not stipulate a maximum 



MSS in the ACK SYN packet, the default used by the client 
is 536 bytes. An MSS option is then added by the proxy 
redirector to inform the client that the maximum MSS 
expected by the other end of the TCP connection is 514 
bytes. 

As previously described, a NAT and PAT are performed 
by proxy redirector 104 on all packets addressed by client 
101-1 to an origin server, and all packets addressed by proxy 
cache 110-1 to proxy redirector 104 for return to the client. 
Proxy redirector 104 thus performs a NAT and a PAT on 
these packets flowing in both direction. If proxy redirector 
104 selects a proxy cache that is located in such a point on 
the network that packets from the proxy cache addressed 
directly to client 101-1 must pass through proxy redirector 
104 due to the network configuration, then proxy redirector 
need only perform a half-NAT on the packets flowing 
through it. Specifically, if proxy redirector 104 selects a 
proxy cache such as proxy cache 117, all packets addressed 
to client 101-1 must pass through proxy redirector 104. 
Proxy redirector 104 thus only needs to transform the 
destination IP address and port number of packets from 
client 101-1 to the IP address and port number of proxy 
cache 117, while maintaining the source IP address and port 
number as those of client 101-1. The packets returned from 
proxy cache 117 will thus be addressed to the client's IP 
address and port number. When they pass through proxy 
redirector 104, they are captured and the transformation of 
the source IP address and port to those of the origin server 
are the only address changes that need to be effected. 

The problems of the prior art with respect to persistent 
connections is obviated in accordance with the present 
invention. As previously noted, during a persistent connec- 
tion plural GET requests can be made by a client. In the prior 
art, as described, each GET request can result in a connec- 
tion from a proxy cache to a different origin server if the 
proxy cache does not have the requested objects. The ability 
of a server to maintain the state of a client's connection 
throughout the duration of the connection is compromised if 
each GET request results in connections to multiple servers. 
In accordance with the present invention, once the IP address 
of the origin server is determined at the initial DNS lookup, 
that same IP address is used by the proxy redirector as a 
prefix to each complete URL in every GET request issued by 
the client throughout the duration of the persistent connec- 
tion. Thus, assuming the proxy cache does not contain any 
of the requested objects, the proxy cache will establish a 
TCP connection to the same origin server in response to each 
GET request generated by the client. It should be noted that 
if plural client GET requests are forwarded by the proxy 
redirector to a proxy cache within a persistent TCP 
connection, ack_seq parameter in packets that flow through 
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the proxy redirector from the proxy following each GET 
request must reflect the cumulative changes effected by 
translating the complete URL to the absolute URL in each of 
the preceding GET requests within the same TCP connec- 
tion. Similarly, in all packets received by the proxy redirec- 5 
tor from the client directed to the origin server within a 
persistent TCP connection, the seq parameter must reflect 
cumulative changes. 

FIGS. 3, and 4, together are flow charts detailing the 
functions of proxy redirector 104 in establishing a TCP 10 
connection to a proxy cache and modifying the GET request 
so that such requests can be transparently forwarded to the 
proxy. At step 301, a SYN packet arrives from the client at 
the proxy redirector At step 302, proxy redirector selects a 
proxy cache based on a load balancing algorithm or on an 15 
arbitrary or random selection. At step 303, proxy redirector 
performs a full NAT, changing the daddr from that of the 
origin server to that of the selected proxy and saddr from that 
of the client to that of the proxy redirector. At step 304 a PAT 
is performed, changing sport to that of a bogus ghost port 20 
number and dport to the proxy's port number. At step 305, 
the SYN packet is sent to the proxy. In response to that SYN 
packet, the proxy responds, at step 306, with a SYN ACK 
packet containing an MSS parameter in the TCP header. At 
step 307, a reverse translation is performed on both the IP 25 
addresses and port numbers, changing saddr and sport to 
those of the origin server and daddr and dport to those of the 
client. At step 308, the MSS field is changed by reducing the 
value of the MSS received from the proxy by 22. At step 
309, the ACK SYN packet is sent to the client. At step 310, 30 
proxy redirector receives a responsive ACK packet from the 
client. At step 311, a full NAT and PAT are performed on that 
packet and, at step 312, the modified packet is sent to the 
proxy, thereby completing the handshake sequence. 

At step 313, a packet containing a GET request is received 35 
from the client. A full NAT is performed at step 314 and a 
PAT is performed at step 315. A determination is made at 
decision step 316 whether this is a first packet in the GET 
request. If yes, at step 317, the IP address of the origin server 
obtained Is from daddr of the arriving packet is prefixed to 40 
the complete URL in the GET request. If, at step 316, the 
packet is not a first packet in a GET request, then, at step 
318, the overflow bytes from the previous GET packet are 
prefixed to those bytes in the current packet and if the total 
number of bytes in the resultant packet is than the actual 45 
MSS sent by the proxy, the overflow bytes greater are 
buffered for prefixing to the next packet. After alternative 
steps 316 or 318, at step 319, a determination is made 
whether the current packet is the last packet of a GET 
request. If not, at step 320, the current packet is sent to the 50 
proxy and the flow returns to step 313 to receive the next 
packet in the GET request from the client. If at step 319, the 
current packet is the last packet in a GET message, then, at 
step 321, the pkt_len parameter of that packet is changed to 
reflect the change in length of the packet. At step 322, the 55 
modified packet is sent to the proxy. 

FIG. 5 illustrates the steps performed by the proxy redi- 
rector for each packet received from the proxy starting from 
the ACK to the GET request through the end of the con- 
nection. At step 501, the proxy redirector receives the ACK 60 
to the GET request, or any other packet that logically follows 
the ACK to the GET request. At step 502, reverse NAT and 
PATs are performed, translating daddr and dport to those of 
the client and saddr and sport to those of the origin server. 
At step 503, ack_jseq is decreased by the amount added in 65 
the preceding GET request. At step 504, the modified packet 
is sent to the client. 
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FIG. 6 illustrates the step performed by the proxy redi- 
rector for each packet destined for the origin server from the 
client that follows the GET request. At step 601, a packet 
subsequent to the GET request is received from the client. At 
step 602, a full NAT and PAT are performed. At step 603, 
seq_no is increased by the amount of bytes added by 
modifying the previous GET request. At step 604, the packet 
is sent to the proxy. 

In the discussion above of FIGS. 3, 4, 5 and 6, it has been 
assumed that the proxy cache is located in a position such 
that packets directed to the client will not automatically flow 
through the proxy redirector. Thus, all packets from the 
proxy are addressed to the proxy redirector. Therefore, for 
packets flowing from the client, and packets flowing from 
the proxy, the proxy redirector performs a full NAT and PAT. 
If however, as previously described, the proxy cache 
selected by the proxy redirector is located on the network so 
that all packets from proxy to the client automatically flow 
through the proxy redirector, then, in the steps shown in 
FIGS. 3, 4, 5 and 6, only a half NAT needs to be performed. 

Although described in conjunction the programmable 
network element shown in FIG. 2, the proxy redirector of the 
present invention could be implemented through other 
means, using hardware, software, or a combination of both. 
As an example, a level 4 switch having a fixed program to 
perform the required packet manipulations required by the 
present invention could be used. 

As described, the proxy cache returns requested objects to 
the address from which a request originated as indicated by 
the saddr and sport parameters in the IP header information, 
which is the address of the proxy redirector 104 when the 
proxy cache is not connected on the network so that all 
responses do not automatically pass through the proxy 
redirector The interactions between the requesting client 
and the proxy cache are transparent to both the client and the 
proxy cache, since the client does not "know** that its request 
is being redirected to the proxy by the proxy redirector, and 
the proxy cache, when receiving a GET request with an 
absolute URL does not know that that absolute URL is not 
being formulated by the client's browser operating in a 
non-transparent mode. Advantageously, the proxy cache 
requires no software modifications and standard proxy 
caches, connected anywhere on the network can be used in 
conjunction with the proxy redirector. If, however, the proxy 
is modified, using a programmable network element as 
previously described, for example, the requested object 
retrieved by the proxy from its own cache or received from 
an origin server, can be sent directly back to the client, 
thereby obviating the need to send such packets back to the 
proxy redirector for address translations and redirection to 
the client. By performing only a half-NAT at the proxy 
redirector and leaving the client's saddr and sport as the 
source IP address and port number in the header of the SYN 
packet, GET request packet(s), and other packets forwarded 
by proxy redirector 104 from the client, the proxy cache can 
return packets responsive to the request directly to the client 
by substituting the origin server's IP address and port 
number as the source address for its own address. If the 
proxy redirector performs a full NAT and PAT, then another 
mechanism must be incorporated to provide the client 
address to the proxy cache, such as incorporating the client 
address information as part of an appendix to the absolute 
address in the modified GET request and stripping the 
appended client address information at the proxy before 
determining whether the requested object is stored in the 
cache or whether a connection to the origin server need be 
made. Advantageously, by sending the packets from the 
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proxy cache directly back to the client, the delay encoun- 
tered by transmitting such packets back to the proxy redi- 
rected for address translation and redirection is eliminated. 
Disadvantageous^, the proxy cache must be modified to 
perform these functions, precluding use of standard avail- 
able proxy caches. 

Although described hereinabove in connection with GET 
requests, the present invention can equally be applied to 
redirection of any type of request message in which the 
token is, for example, GET, POST or HEAD, or any other 
type of token yet to be implemented and/or standardized. 

The foregoing therefore merely illustrates the principles 
of the invention. It will thus be appreciated that those skilled 
in the art will be able to devise various arrangements which, 
although not explicitly described or shown herein, embody 
the principles of the invention and are included within its 
spirit and scope. Furthermore, all examples and conditional 
language recited hereinabove are principally intended 
expressly to be only for pedagogical purposes to aid the 
reader in understanding the principles of the invention and 
the concepts contributed by the inventors to furthering the 
art, and are to be construed as being without limitation to 
such specifically recited examples and conditions. 
Moreover, all statements hereinabove reciting principles, 
aspects, and embodiments of the invention, as well as 
specific examples thereof, are intended to encompass both 
structural and functional equivalents thereof. Additionally, it 
is intended that such equivalents include both currently 
known equivalents as well as equivalents developed in the 
future, i.e., any elements developed that perform the same 
function, regardless of structure. 

Thus, for example, it will be appreciated by those skilled 
in the art that the block diagrams and flowcharts described 
hereinabove represent conceptual views of illustrative cir- 
cuitry and processes embodying the principles of the inven- 
tion. Similarly, it will be appreciated that any flowcharts, 
flow diagrams, state transition diagrams, pseudocode, and 
the like represent various processes which may be substan- 
tially represented in computer readable medium and so 
executed by a computer or processor, whether or not such a 
computer or processor is explicitly shown. 

The functions of the various elements shown in the FIGS., 
including functional blocks labeled as "processors" may be 
provided through the use of dedicated hardware as well as 
hardware capable of executing software in association with 
appropriate software. When provided by a processor, the 
functions may be provided by a single dedicated processor, 
by a single shared processor, or by a plurality of individual 
processors, some of which may be shared. Moreover, 
explicit use of the term "processor" or "controller" should 
not be construed to refer exclusively to hardware capable of 
executing software, and may implicitly include, without 
limitation, digital signal processor (DSP) hardware, read- 
only memory (ROM) for storing software, random access 
memory (RAM), and non-volatile storage. Other hardware, 
conventional and/or custom, may also be included. 
Similarly, any switches shown in the FIGS, are conceptual 
only. Their function may be carried out through the opera- 
tion of program logic, through dedicated logic, through the 
interaction of program control and dedicated logic, or even 
manually, the particular technique being selectable by the 
implementor as more specifically understood from the con- 
text. 

In the claims hereof any element expressed as a means for 
performing a specified function is intended to encompass 
any way of performing that function including, for example, 
a) a combination of circuit elements which performs that 
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function or b) software in any form, including, therefore, 
firmware, microcode or the like, combined with appropriate 
circuitry for executing that software to perform the function. 
The invention as defined by such claims resides in the fact 

5 that the functionalities provided by the various recited 
means are combined and brought together in the manner 
which the claims call for. Applicant thus regards any means 
which can provide those functionalities as equivalent to 
those shown hereinabove. 

10 What is claimed is: 

1. A method at a Layer 4 switch for redirecting an HTTP 
connection request from a client that is directed to an origin 
server to a proxy cache over a packet-based computer 
network comprising the steps of: 

15 receiving at least one packet containing a request message 
within the HTTP connection, the at least one packet 
having an IP header comprising a destination address of 
an origin server, the request message including a com- 
plete address of a specified object at the origin server; 

20 modifying, at the packet level, the request message by 
combining the destination address of the origin server 
with the complete address; and 
forwarding the at least one packet containing the modified 
request message to the proxy cache over the packet- 

25 based network; 

wherein the proxy cache is a standard proxy cache and, in 
the forwarding step, the at least one packet containing 
the modified request is redirected to the standard proxy 

^ cache transparently from the standpoints of both the 
client and the proxy cache, the proxy cache being able 
to determine whether it can satisfy the request for the 
specified object by using the combined destination 
address of the origin server and the complete address 

35 contained in the modified request message. 

2. The method of claim 1 wherein the step of modifying 
comprises the step of prefixing the complete address in the 
request message with the destination address of the origin 
server. 

^ 3. The method of claim 2 further comprising the step of: 
translating the destination address in an IP header of the 
at least one packet containing the modified request 
message to the address of the proxy cache. 

4. The method of claim 3 further comprising the step of: 
45 translating a source address in the IP header of the at least 

one packet containing the modified request message 
from an address of the client to an address of the Layer 
4 switch. 

5. The method of claim 3 further comprising the step of: 
50 in a TCP header in packets received from the proxy cache 

commencing with an acknowledgment to the modified 
request message, modifying a value in an acknowl- 
edged byte sequence number field to reflect the 
increased number of bytes in the modified request 
55 message resulting from the step of prefixing the com- 
plete address with the destination address of the origin 
server. 

6. The method of claim 5 wherein the step of modifying 
the value in the acknowledged byte sequence number field 

60 comprises the step of decreasing the value in the acknowl- 
edged byte sequence number field by the number of bytes 
added by prefixing the destination address of the origin 
server to the complete address in the request message. 

7. The method of claim 6 further comprising the step of: 
65 translating in the IP header the destination address to the 

address of the client and the source address to that of 
the origin server in the packets received from the proxy 
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cache commencing with the acknowledgment to the 
request message. 

8. The method of claim 3 further comprising the step of: 
modifying a value in a sent byte sequence number field to 

reflect the increased number of bytes in the modified 5 
request message resulting from prefixing the complete 
address with the destination address of the origin server 
in a TCP header in packets received from the client 
following receipt of the request message. 

9. The method of claim 8 wherein the step of modifying 1Q 
the value in the sent byte sequence number field comprises 
the step of increasing the value in the sent byte sequence 
number field by the number of bytes added by prefixing the 
destination address of the origin server to the complete 
address in the request message. 

10. The method of claim 9 further comprising the step of: 15 
translating the destination address to the address of the 

proxy cache in the IP header in each packet received 
from the client following receipt of the request mes- 
sage, 2Q 

11. The method of claim 2 further comprising, prior to the 
step of receiving the at least one packet containing the 
request message, the steps of: 

receiving a packet from the proxy cache indicating a 
maximum segment size that packets sent to it thereafter ^ 
should have; 

reducing by a predetermined number the maximum seg- 
ment size of packets to be thereafter sent to the proxy 
cache; and 

sending a packet to the client indicating the reduced 30 
maximum segment size that packets thereafter sent by 
the client to the origin server should have. 

12. The method of claim 11 wherein the predetermined 
number is equal at least to the maximum number of bytes 
added by the step of prefixing the destination address to the 35 
complete address in the request message. 

13. The method of claim 12 further comprising the steps 

of: 

successively shifting to a next packet in the request 
message overflow bites caused by the step of prefixing 40 
the destination address to the complete address in the 
request message, if the request message is contained 
within more than one packet; and 

changing a length-of-packet parameter in the IP header in 
a last packet of a multi-packet request message to 45 
reflect the bytes shifted into the last packet from a 
previous packet. 

14. The method of claim 12 further comprising the step of 
changing a length-of-packet parameter in the IP header to 
reflect the change in the length of that packet caused by the 50 
step of prefixing the destination address to the complete 
address in the request message, if the request message is 
contained within one packet. 

15. The method of claim 1 wherein the request message 
is a GET request. 55 

16. The method of claim of claim 1 further comprising the 
step of selecting the proxy cache from a plurality of different 
proxy caches prior to receiving the at least one packet 
containing the request message. 

17. The method of claim 1 wherein the request message 60 
is a POST request. 

18. The method of claim 1 wherein the request message 
is a HEAD request. 

19. A proxy redirector for redirecting an HTTP connection 
request from a client that is directed to an origin server to a 65 
proxy cache over a packet-based computer network com- 
prising: 
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means for receiving at least one packet containing the 
request message, the a least one packet having an IP 
header comprising a destination address of an origin 
server, the request message including a complete 
address of a specified object at the origin server; 
means for modified the request message by combining the 
destination address of the origin server with the com- 
plete address at the packet level; and 
means for forwarding the at least one packet containing 
the modified request message to the proxy cache over 
the packet-based network; 
wherein the proxy cache is a standard proxy cache and the 
means for forwarding redirects the at least one packet 
containing the modified request to the standard proxy 
cache transparently from the standpoints of both the 
client and the proxy cache, the proxy cache being able 
to determine whether it can satisfy the request for the 
specified object by using the combined destination 
address of the origin server and the complete address 
contained in the modified request message. 

20. The proxy redirector of claim 19 wherein the means 
for modifying comprises means for prefixing the complete 
address in the request message with the destination address 
of the origin server. 

21. The proxy redirector of claim 20 further comprising: 
means for translating the destination address in an IP 

header of the at least one packet containing the modi- 
fied request message to the address of the proxy cache. 

22. The proxy redirector of claim 21 further comprising: 
means for translating a source address in the IP header of 

the at least one packet containing the modified request 
message from an address of the client to an address of 
the proxy redirector. 

23. The proxy redirector of claim 21 further comprising: 
means for modifying a value in an acknowledged byte 

sequence number field in a TCP header in packets 
received from the proxy cache, commencing with an 
acknowledgment to the modified request message, to 
reflect the increased number of bytes in the modified 
request message resulting from prefixing the complete 
address with the destination address of the origin 
server. 

24. The proxy redirector of claim 23 wherein the means 
for modifying the value in the acknowledged byte sequence 
number field decreases the value in the acknowledged byte 
sequence number field by the number of bytes added by 
prefixing the destination address of the origin server to the 
complete address in the request message. 

25. The proxy redirector of claim 24 further comprising: 
means for translating in the IP header the destination 

address to the address of the client and the source 
address to that of the origin server in the packets 
received from the proxy cache commencing with the 
acknowledgment to the request message. 

26. The proxy redirector of claim 21 further comprising: 
means for modifying a value in a sent byte sequence 

number field to reflect the increased number of bytes in 
the modified request message resulting from prefixing 
the complete address with the destination address of the 
origin server in a TCP header in packets received from 
the client following receipt of the request message. 

27. The proxy redirector of claim 26 wherein the means 
for modifying the value in the sent byte sequence number 
field increases the value in the sent byte sequence number 
field by the number of bytes added by prefixing the desti- 
nation address of the origin server to the complete address 
in the request message. 
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28. The proxy redirector of claim 27 further comprising: 
means for translating the destination address to the 

address of the proxy cache in the IP header each packet 
received from the client following receipt of the request 
message. 

29. The proxy redirector of claim 20 further comprising: 
means for receiving a packet from the proxy cache 

indicating a maximum segment size that packets sent to 
it thereafter should have; 

means for reducing by a predetermined number the maxi- 
mum segment size of packets to be thereafter sent to the 
proxy cache; and 

means for sending a packet to the client indicating the 
reduced maximum segment size that packets thereafter 
sent by the client to the origin server should have. 

30. The proxy redirector of claim 29 wherein the prede- 
termined number is equal at least to the maximum number 
of bytes added by the prefix of the destination address to the 
complete address in the request message. 

31. The proxy redirector of claim 30 further comprising: 
means for successively shifting to a next packet in the 

request message overflow bytes caused by the prefix of 
the destination address to the complete address in the 
request message, if the request message is contained 
within more than one packet; and 
means for changing a length-of-packet parameter in the IP 
header in a last packet of a multi-packet request mes- 
sage to reflect the bytes shifted into the last packet from 
a previous packet. 

32. The proxy redirector of claim 30 wherein the proxy 
cache further comprises means for changing a length-of- 
packet parameter in the IP header to reflect the change in the 
length of that packet caused by the prefix of the destination 
address to the complete address in the request message, if 
the length of the request message is contained within one 
packet. 

33. The proxy redirector of claim 19 further comprising 
means for selecting the proxy cache from a plurality of 
different proxy caches. 

34. The proxy redirector of claim 19 wherein the means 
for modifying the request message is a gateway program 
dynamically loaded on a programmable network element. 

35. The proxy redirector of claim 19 wherein the request 
message is a GET request. 

36. The proxy redirector of claim 19 wherein the request 
message is a POST request. 

37. The proxy redirector of claim 19 wherein the request 
message is a HEAD request. 

38. A computer readable medium storing computer pro- 
gram instructions which are executable on a computer 
system implementing a Layer 4 switch for redirecting an 
HTTP connection request from a client to a proxy cache over 
a packet-based computer network, said computer program 
instructions comprising instructions defining the steps of: 

receiving at least one packet containing the request 
message, the at least one packet having an IP header 
comprising a destination address of an origin server, the 
request message including a complete address of a 
specified object at the origin server, 

modifying, at the packet level, the request message by 
combining the destination address of the origin server 
with the complete address; and 

forwarding the at least one packet containing the modified 
request message to the proxy cache over the packet- 
based network; 

wherein the proxy cache is a standard proxy cache and, in 
the forwarding step, the at least one packet containing 
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the modified request is redirected to the standard proxy 
cache transparently from the standpoints of both the 
client and the proxy cache, the proxy cache being able 
to determine whether it can satisfy the request for the 
5 specified object by using the combined destination 
address of the origin server and the complete address 
contained in the modified request message. 

39. The computer readable memory of claim 38 wherein 
the step of modifying comprises the step of prefixing the 

1Q complete address in the request message with the destination 
address of the origin server. 

40. The computer readable memory of claim 39 wherein 
said computer program instructions further comprise 
instructions defining the step of: 

translating the destination address in an IP header of the 
15 at least one packet containing the modified request 
message to the address of the proxy cache. 

41. The computer readable memory of claim 40 wherein 
said computer program instructions further comprise 
instructions defining the step of: 

20 translating a source address in the IP header of the at least 
one packet containing the modified request message 
from an address of the client to an address of the Layer 
4 switch. 

42. The computer readable memory of claim 40 wherein 
25 said computer program instructions further comprise 

instructions defining the step of: 

in a TCP header in packets received from the proxy cache 
commencing with an acknowledgment to the modified 
request message, modifying a value in a acknowledged 
30 byte sequence number field to reflect the increased 
number of bytes in the modified request message 
resulting from the step of prefixing the complete 
address with the destination address of the origin 
server. 

35 43. The computer readable memory of claim 42 wherein 
the step of modifying the value in the acknowledged byte 
sequence number field comprises the step of decreasing the 
value in the acknowledged byte sequence number field by 
the number of bytes added by prefixing the destination 
40 address of the origin server to the complete address in the 
request message. 

44. The computer readable memory of claim 43 wherein 
said computer program instructions further comprise 
instructions defining the step of: 
45 translating in the IP header the destination address to the 
address of the client and the source address to that of 
the origin server in the packets received from the proxy 
cache commencing with the acknowledgment to the 
request message. 
50 45. The computer readable memory of claim 40 wherein 
said computer program instructions further comprise 
instructions defining the step of: 

modifying a value in a sent byte sequence number field to 
reflect the increased number of bytes in the modified 
55 request message resulting from prefixing the complete 
address with the destination address of the origin server 
in a TCP header in packets received from the client 
following receipt of the request message. 
46. The computer readable memory of claim 45 wherein 
60 the step of modifying the value in the sent byte sequence 
number field comprises the step of increasing the value in 
the sent byte sequence number field by the number of bytes 
added by prefixing the destination address of the origin 
server to the complete address in the fequest message. 
65 47. The computer readable memory of claim 46 wherein 
said computer program instructions further comprise 
instructions defining the step of: 
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translating the destination address to the address of the request message, if the request message is contained 

proxy cache in the IP header each packet received from within more than one packet; and 

the client following receipt of the request message. changing a length-of-packet parameter in the IP header in 

48. The computer readable memory of claim 39 wherein a last packet of a multi-packet request message to 
said computer program instructions further comprises 5 reflect the bytes shifted into the last packet from a 
instructions defining, prior to the step of receiving the at previous packet. 

least one packet containing the request message, the steps of: 51- Th e computer readable memory of claim 49 wherein 

receiving a packet from the proxy cache indicating a ™* C ° mpU Jf' F"*!™ ^ructions further comprise 

maximum segment size that packets sent to it thereafter "■"tenons defining the step of changing a length-of-packet 

should have* 10 P arameter m me ^ header to reflect the change in the length 

, . . ' . 4 . of that packet caused by me step of prefixing the destination 

reducing by a predetermined number the maximum seg- addrcss to ^ lete addrcss m me reque st message, if 

ment size of packets to be thereafter sent to the proxy me ^ m e fa contained within one packet. 

' 52. The computer readable memory of claim of claim 38 
sending a packet to the client indicating the reduced J5 wherein said computer program instructions further corn- 
maximum segment size that packets thereafter sent by prise instructions defining the step of selecting the proxy 
the client to the origin server should have. cac he from a plurality of different proxy caches prior to 

49. The computer readable memory of claim 48 wherein receiving the at least one packet containing the request 
the predetermined number is equal at least to the maximum message. 

number of bytes added by the step of prefixing the destina- 2Q 53. Th e computer readable memory of claim 38 wherein 

tion address to the complete address in the request message. the request message is a GET request. 

50. The computer readable memory of claim 49 wherein 54. The computer readable memory of claim 38 wherein 
said computer program instructions further comprise the request message is a POST request. 

instructions defining the steps of: 55 The computer readable memory of claim 38 wherein 

successively shifting to a next packet in the request 25 the request message is a HEAD request, 
message overflow bytes caused by the step of prefixing 

the destination address to the complete address in the * * * * * 



